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(57) Abstract: Method of authenticating a client comprising the steps of sending a subscriber identity to an authentication server; 
obtaining at least one challenge and at least one first secret to the authentication server based on a client's secret specific to the client; 
forming first credentials; forming a first authentication key using the at least one first secret; encrypting the first credentials using the 
first authentication key; sending the at least one challenge and the encrypted first credentials to the client; forming an own version 
of the first authentication key at the client; decrypting the encrypted first credentials using the own version of the first authentication 
key. In the method, the encrypted credentials are sent together with the at least one challenge to the client so that the client can 
proceed authentication only if it can derive the first secret from the at least one challenge. 
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AUTHENTICATION IN DATA COMMUNICATION 

This invention relates to authentication in data communication. In particular the 
invention relates to, but is not limited to, authenticating mobile stations and 
5 network servers communicating with each other through a network such as the 
Internet. 

The Internet is used to share public information. Since it is an open system, it 
should not be used to share confidential information unless precautions are taken 
K ^A0 to protect the information by use of passwords, encryption and the like. Even so, if 
passwords are used, they can be determined by hackers. In the Internet, there are 
clients (typically personal computers with computer programs) and servers (server 
computers running computer programs that cause them to provide services to the 
clients). Typically computer programs used at clients and servers assume that 
15 their users are honest about their identity. Some client/server applications rely on 
the client to restrict its activities to those which it is allowed to do, with no other 
enforcement by the server. Strong authentication is highly desirable for 
transactions involving money, confidential data or both. 

20 One way to improve the situation is to use dedicated authentication protocols and, 
if necessary, encryption protocols for verifying the authenticity of a party and for 
preventing unauthorised parties from obtaining access. In addition, these protocols 
can typically be used to verify the integrity of any information exchanged over a 
link so that a recipient can be certain that the data received have not been 

25 tampered with. 

Kerberos is a protocol designed to provide strong authentication for client/server 
applications by using secret-key cryptography. At least two versions of Kerberos 
have been described, versions 4 and 5. The version 5 Kerberos has been 
30 described by J. Kohl and C. Neuman in "The Kerberos Network Authentication 
Service (Version 5) u , RFC 1510, September 1993. Versions 4 and 5 have also 
been described by W. Stallings, "Cryptography and Network Security, Principles 
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and Practice", 2nd edition, p. 323-340. These two versions of Kerberos are briefly 
described in the following passages. 

Fig. 1 shows an overview of a Kerberos system KS according to Kerberos version 
4. The Kerberos system KS comprises a client c which can obtain access to the 
Internet, a Kerberos server KSS in the Internet and a service server V for providing 
a service for which authentication is required. The Kerberos server KSS comprises 
an authentication server AS, a ticket-granting server TGS, and a database DB 
comprising (hashed) passwords of different clients. The client c contains a 
personal computer (PC), comprising an Input/Output module IO c (such as a 
modem or a network adapter) for connecting to the Internet, a central processing 
unit CPU C for processing data and a memory MEM C . The memory has a non^ 
volatile portion for storing applications for controlling the CPU C and a random 
access memory portion for use in processing data. Additionally, the client c has a 
user interface Ul for interacting with a user. The Ul may prompt a user to give a 
password and may receive the password. In a Kerberos system, the applications 
together with the personal computer form the client c that can use services of a 
host (computer) accessible through an insecure network. 

The V is a server that provides service to the client c. It authenticates the client c 
by using a sequence of authentications, in which the client c is first authenticated 
to the AS to obtain a ticket granting ticket ticket tgs . Using the ticket tgs the client c 
can next obtain a service granting ticket ticket v . This ticket can then be used for 
the service. This procedure will be explained in detail with reference to Fig.s 1 and 
2. 

In order to work, the Kerberos system should already have a first shared secret (or 
first authentication key, K c ) known by the client c, the AS and the TGS. A second 
shared secret (K v ) should be known by the AS, the TGS and the service server V, 
but not by the client c. These shared secrets are presumed to exist. 

For any particular secret to be known by any particular party it is sufficient that the 
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party can, when necessary, obtain the secret, for example by asking the user 
(party being a client) or by requesting it from the database (party being an AS or 
TGS). Typically, the TGS and AS are co-located, but in some cases the Kerberos 
server KSS can also be distributed so that the TGS and AS are not co-located. 

5 

Operation of the Kerberos system KS as a sequence of steps is illustrated in Fig. 
2. In brief, Fig. 2 shows messaging between the user, client c, authentication 
server AS, ticket granting server TGS and service server V. For convenience, the 
notation here will follow that used in the above mentioned publication of Stallings. 
1 0 The steps of Fig. 2 will now be described. 

Step 21: The user logs on to the client c and requests a desired service on the 
service server (host) by sending a login and a service request. To log on, the user 
enters a client's password K c that is known by him and the authentication server. 
1 5 The client's password is the first shared secret. From now on, K c is referred to as a 
first authentication key. 

Step 22: The client c sends to the AS a request for a ticket granting ticket ticket tgs . 
The request comprises the ID of the client c (ID C ), the ID of the TGS (ID tgs ), and a 

20 first time stamp TS n corresponding to the time when the request was sent. 

J 

Step 23: The AS forms a ticket tgs using a second authentication key K tgs known by 
the AS and the TGS but not by the client c. The ticket tgs = E Ktgs [ K c , tgs II ID C II AD C II 
ID tgs II TS 2 II Lifetime 2 ]. E represents an encryption algorithm using a second 

25 authentication key K tgs as its encryption key. K c ,t gs is a first session key formed by 
the AS (for example, a random key) for use between the client c and the TGS. AD C 
is the address of the client c, ID tgs is an identity of the TGS, TS 2 is second time 
stamp showing the time of the issue of the ticket tgs and Lifetime 2 is the time of 
expiry of the ticket tgs . The bars "II 11 indicate concatenation. The ticket tgs is to be 

30 used later for obtaining service granting tickets (ticket v ) for using various services. 
Then the AS encrypts data using the K c as follows: Ek c [ K Cl t gs II ID tgs II TS 2 II 
Lifetime 2 ] and sends the ticket tgs and the encrypted data to the client c. 
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Step 24: The client c then prompts for the K c from its user. The user should know 
the K c . 

5 Step 25: The user provides the client c with the K 0 . 

Step 26: Using the K c and the K C(t gs, the client c decrypts the encrypted data 
received from the AS and forms a first client authenticator, authenticator c i = E K ♦ \ 
IDc II AD C II ID V II TS 3 ]. ID V is the ID of the V and TS 3 is the time of forming the 
10 authenticator c i. As a skilled reader will understand, the client c is only able to * > 

derive the Kc.tgs if it knows the Kc. The authenticated is later used by the TGS to 
authenticate the client c. The client c then sends a request for a service granting 
ticket (ticket v ) to the TGS. The request contains ID V) ticket tgs and authenticate^. 

15 Step 27: The TGS forms the ticketv and sends it together with an encrypted 
second session key K c , v to the client c. The second session key is encrypted with 
the first session key K c ,tg S . The ticketv is formed by the TGS using the knowledge 
of a second shared secret K v of the V, as follows: ticketv = E Kv [ K c , v II ID C II AD C II 
ID V II TS 4 II Lifetime 4 ], wherein: 

20 K c ,v is a second session key for use between the client c and V, 

) 

TS 4 is a time stamp showing the time of forming the ticket v> and J - 
Lifetime 4 sets the lifetime of the ticketv to prevent replay attacks after 
the expiry of the lifetime of the ticket v . 

25 Step 28: The client c sends a service request to the V. The request contains the 
ticketv and a second client authenticator, authenticator C 2, wherein authenticator o2 = 
e k c ,v[ ID c 'I AD C II TS 5 ]. TS5 is a time stamp showing the time of forming the 
second client authenticator. 



30 



Step 29: After the service server V has examined the authenticator o2 , it can 
authenticate itself to the client c for mutual authentication. This is done by replying 
with the TS 5 , incremented by 1 and encrypted with the Kc.v, so that the client c can 
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trust that V is the correct server since it can encrypt with the same K c ,v. The reply 
is thus Ek CiV [TS5 + 1 ]. 

The steps 22 and 23 occur once for each user logon session. The ticket tgs is thus 
5 valid for the duration of the user logon session (or until it expires). The steps 26 
and 27 occur once for each type of service. In other words, for each type of 
service, a different ticketv is applied for and is granted. The steps 28 and 29 occur 
once for each service session of a granted service type. 

/- — . 

~ -Ho The description of Fig. 2 illustrates how Kerberos can provide centralised 
authentication to a plurality of different service servers that trust the Kerberos 
server KSS (the combination of AS and TGS). The KSS has a different second 
shared secret K v with each V and each V is registered with the KSS. 

15 The system of Fig. 1 represents one realm: For example, a single employer in one 
country or city owns all the entities. 

Kerberos version 5 provides some refinements over version 4, including allowing a 
plurality of Kerberos realms to inter-operate so that one authentication server AS 
_ 20 can grant service granting tickets ticketv to service servers V of different 
- y authentication realms. 

The operation of a Kerberos system according to Kerberos version 5 will next be 
described with reference to Fig. 1. In Kerberos version 5, the authentication and 
25 key distribution starts with an Authentication Service Exchange procedure, where 
the client c requests a ticket tgs from the AS, and the AS forms and sends the 
tickettgs and other parameters encrypted with the K c in response. The ticket tgs and 
the K Cit gs key will be used as credentials for obtaining service granting tickets 
(ticket v ) for using services. The Authentication Service Exchange is as follows: 

30 

(1) from c to AS message KRB_AS_REQ = Options II ID C II Realm c II ID tgs II times 
II Noncei 
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(2) from AS to c, message KRB_AS_REP = realm c II ID C II ticket, gs II E Kc [K c>tgs II 
times II nonce! II realm t g S II ID tgs ] 



VVI ItM 


ticKettgs = t K tgs|tlags ll K Cf tgs 11 realm c II ID C II AD C II times] 


5 and wherpin 

w LA. 1 i VVI Iwl vll 1 




opxions 


various options used to request that certain flags be set in the 




returned ticket 


flags 


various message flags for use in the Kerberos version 5 protocol 


realmc 


realm of the client 


1 0 realm t gs 


realm of the TGS 


times 


start time, expiration time and renewal time of the ticket tgs 


noncei 


a random value generated by the client to ensure that the response 




is fresh (not a copy of an earlier response) 



15 One should bear in mind that different types of fields may be encrypted together, 
because all the different types are ultimately represented by binary codes (zeros 
and ones), which can be operated within the same function regardless their origin. 

The K c is used to encrypt the K c>t gs and other parameters in the KRB_AS_REP 
20 message. It should be noted that in Kerberos, anyone can request a ticket tgs but 

only the valid client is able to use it. Because only the valid client knows the K c , ) 
others are not able to decrypt the Kc,t gs which is required when using the ticket tgs . 
In Kerberos, the K c is only used in the KRB_AS_REP message to encrypt the Kc, t gs 
and other parameters. Different session keys are used instead of the K c in all other 
25 Kerberos messages. 

With the tickettgs and K c ,t gs , the client c is able to obtain new versions of ticketv and 
Kc.v from the TGS. The new versions can further be used to obtain service from 
the Vs. 

30 

Authentication may also be needed in mobile, communications networks. At 
present, there are various types of mobile communications networks, with different 
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types of authentication procedures. Typically, digital mobile communications 
networks, such as GSM, provide digital authentication of a subscriber in order to 
support invoicing of the a network operator running the network. In GSM, the 
authentication is based on using GSM triplets, which are generated by dedicated 
5 Subscriber Identity Modules (SIM) at a subscriber's end and at an Authentication 
Centre (AuC) of the network operator. The AuC is typically functionality provided 
by a Home Location Register (HLR) of a GSM network. In GSM, the GSM triplets 
can be used in a rather relaxed way, so that their order is not strictly fixed. In the 
forthcoming Universal Mobile Telecommunications System (UMTS) the 
l _10 authentication differs from GSM. An overview of the authentication in UMTS is 
given in the 3rd Generation Partnership Project (3GPP) Technical Specification 
(TS) 33.102 V3.6.0 (2000-10), paragraph 6.3, and abstracted in the following: 

In UMTS, the user authentication modules are referred to as UMTS subscriber 
15 identity modules (USIMs) and the AuC generates authentication vectors, or 
quintets, which comprise the following components: a random number RAND, an 
expected response XRES, a cipher key CK, an integrity key IK and an 
authentication token AUTN. Each authentication vector is good for one 
authentication. RAND, XRES and CK roughly correspond to RAND, SRES and Kc 
20 of GSM, but particularly AUTN and its use form a significant difference over GSM. 
The AUTN is based, among others, on a sequence number SQN corresponding to 
a particular authentication vector. 

WO00/02406 provides a method, which allows clients in a mobile IP (IP, Internet 
25 Protocol) network to generate a K c by using a Subscriber Identity Module (SIM) of 
a GSM operator. The GSM operators have databases containing the identities of 
subscribers and their secret data. In GSM, the secret stored on a SIM is referred 
to as Ki. The SIM has capability to generate a GSM session key K gsm , a one-way 
hashed signed response SRES of a challenge RAND based on the secret Ki. This 
30 procedure of WO00/02406 is shown as a series of steps 31 to 37 in Fig. 3. 

A security server SS (corresponding to a KSS) sends (step 31) an authentication 



I 
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ID request to a terminal TE1 (corresponds to a client c). The client c responds 
(step 32) by its International Mobile Subscriber Identity (IMSI). The security server 
sends (step 33) a security information request to a proxy server. The proxy server 
acquires (step 34) the security information from a Home Location Register of a 
5 GSM operator whose SIM is being used, containing a GSM triplet (Kg Sm , RAND 
and challenge). The proxy server sends (step 35) the GSM triplet to the security 
server. The security server sends (step 36) the challenge RAND to the client c. 

Step 37: The client c forms its own version of the GSM session key K gsm and 
10 SRES corresponding to its Ki and the RAND received. Then the client c sends i J 

back the SRES so that the security server can compare it against the SRES it 
received in the GSM triplet from the proxy server. If the SRES provided by the 
proxy server and the SRES generated by the client c match, a positive 
authentication is made and the security server can start using the GSM session 
15 key K gsm as the K c between the client c and a security server (that is, a Kerberos 
server). 

WO00/02406 combines GSM technology with Kerberos technology. Instead of 
authenticating a wireless mobile telephone by a GSM network by using the GSM 
20 triplets and comparing different responses against each other, the SIM is used for 

generating a response to a challenge received from a mobile IP network. The J 
response is then sent to the mobile IP network for comparison against the correct 
answer for the Ki and RAND for detecting that the client c is genuine and is not 
trying to illegitimately access services using an IMSI of another client. 

25 

According to a first aspect of the invention there is provided a method of 
authenticating a client, comprising the steps of: 

sending client identity information to an authentication block; 

obtaining at least one challenge and at least one first secret for the 
30 authentication block based on a client's secret specific to the client; 

forming first credentials; 

forming a first authentication key using the at least one first secret; 
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encrypting the first credentials using the first authentication key; 

sending the at least one challenge and the encrypted first credentials to the 

client; 

forming the first authentication key at the client; 
5 decrypting the encrypted first credentials at the client using the first 

authentication key; characterised in that 

the encryption of the first credentials are independent of the authentication 
block receiving any response based on the client's secret from the client. 

{ ._ ,10 The method of the first aspect can be understood as a client sending a request 
message to an authentication block and directly responsive to the request 
message, the client receives the encrypted first credentials containing an 
authenticating ticket and decrypts the first credentials using the secret specific to 
the client. This allows the client to obtain the first credential without an 
15 intermediate step of sending back to the authentication block any response based 
on the client's secret. 

Preferably, the authentication block is located in a data communication network. 
Even more preferably, a network server provides the authentication block. 

20 

[ .J Preferably, the first credentials are encrypted before the authentication block 
receives any response based on the client's secret from the client. 

Preferably, the encrypted first credentials are sent together with the at least one 
25 challenge to the client. 

Even more preferably, no response based on the client's secret is sent from the 
client to the authentication block. Not sending any such response makes it further 
possible to use the entire first secret in forming the first authentication key, which 
30 cryptographically strengthens it. 

Preferably, the challenge is a random code. 
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Preferably, the forming of the first authentication key is based on two or more first 
secrets. This further strengthens cryptographically the first authentication key. 

5 The invented method is based on a new approach to a problem of creating a first 
shared secret between an authentication block and the client. In the invention, it 
has been realised that it is possible to form the first credentials, the first 
authentication key and to encrypt the first credentials with the first authentication 
key when the authentication block obtains the challenge and the first secret. 

10 Cryptography is used for both indirect authentication and for delivery of the first ' - 
credentials. Only if the client has resolved the first authentication key correctly, it 
can decrypt the first credentials. The client can then form a service request 
message using cryptographically the first decrypted credentials and so it can 
become authenticated as a by-product of the forming the service request 

15 message. This provides significant advantages. The method allows secure and 
fast authentication, in which the first credentials are formed and then sent with the 
at least one challenge without need to first separately authenticate the client. This 
makes the method usable with various known authentication methods including 
the Kerberos versions 4 and 5 and also reduces the amount of communications 

20 signals which need to be sent and received. The method further makes it 

unnecessary for an authentication block to store the first secret after forming the ^ 
first authentication key and the first credentials. This reduces the complexity of the 
authentication process and makes it quicker, because some messaging becomes 
redundant. The authentication is also stronger, if all the data contained by the first 

25 secret is used in forming the first authentication key. This was not possible in the 
prior art, where a signed response (SRES) was transmitted from the client to the 
authentication block as clear text so that any third party could have easily obtained 
it. 

30 Preferably, the step of obtaining the at least one challenge and at least one first 
secret for the authentication block based on a client's secret specific to the client 
occurs before a need to authenticate the client. Even more preferably, a collection 
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of challenges and first secrets sufficient for forming at least two first credentials for 
the client is obtained in a batch. Preferable still, such collection is obtained for a 
group of clients so that the authentication block has the data already available for 
authenticating any of the clients of the group without needing to first obtain them. 
5 This allows faster authentication of a group of clients belonging to the same 
organisation or group as the data relating to their client's secrets are already 
available to the authentication block and need not be separately obtained on each 
authentication of a client. 

„ I0 Preferably, the client identity information is subscriber identity. Even more 
preferably, the authentication block forms an identification for use in further 
authentication messages for the client so that the subscriber identifier need not be 
included in them. 

15 Preferably, the first authentication key is formed using a hash function of at least 
one first secret. Even more preferably, the first authentication key is formed using 
a hash function of at least the first secret and the replay attack protector. The 
using of the replay attack protector in forming the first authentication key and the 
using of a hash function makes it possible for the authentication block to 

20 authenticate to the client. 

In an alternative embodiment, the forming of the first authentication key is based 
on a part of a first secret 

25 Preferably, the forming of the first credentials comprises the sub-steps of: 

encrypting first information corresponding to the client with a second 

authentication key not known by the client; and 

verifying that the first information has been encrypted using the second 

authentication key. 

30 

Preferably, the method further comprises the step of generating a service request 
message using cryptographically the first decrypted credentials. 
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Preferably, the first information contains at least one of the items selected from a 
group consisting of: the identity of the client, the identity of the ticket granting 
server, the realm of the client, and a time stamp. 

5 

Preferably, the client is a multifunction mobile terminal having at least mobile 
telecommunications functionality and packet data network communications 
functionality. Even more preferably, the mobile telecommunications functionality 
supports the Global System for Mobile Communications. This provides a large 
10 base of already existing subscriber identity modules (SIMs) in use for 4 J 

authenticating the clients in different data communication networks other than the 
telecommunications networks. 

Preferably, the mobile telecommunications functionality supports a 
15 telecommunications system wherein ordered authentication vectors are used. 

Preferably, the at least one challenge and the at least one first secret correspond 
to particular at least one sequence number and convey the at least one sequence 
number, and the method further comprises the steps of: 
20 maintaining a sequence number counter at the client; 

obtaining at the client the sequence number using at least one of the at ) 
least one challenge and the at least one first secret; and 

checking at the client if the sequence number is in a correct range about the 
sequence number counter. 

25 

Preferably, the method further comprises the step of initiating sequence number 
synchronisation in case the sequence number is not in the correct range about the 
sequence number counter. 



30 



Preferably, the initiating sequence number synchronisation comprises a step of 
forming a synchronisation request message containing at least one challenge out 
of the at least one challenge. 
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Preferably, the initiating sequence number synchronisation comprises a step of 
forming a synchronisation request message containing at the sequence number 
counter. 

5 

Preferably, the synchronisation request message further comprises a message 
authentication code. 

Preferably, the checking the first credentials is based on the sequence number 
! _^I0 and comprises the steps of maintaining a sequence number counter by the client; 
and determining whether at least one parameter of the first credentials have been 
computed using the sequence number. Preferably the determining whether at 
least one parameter of the first credentials have been computed using the 
sequence number is based on the sequence number and an exclusive or 
15 operation. 

According to a second aspect of the invention there is provided a method of 
authenticating a client, comprising the steps of: 

sending client identity information to an authentication block; 
20 receiving by the client at least one challenge and encrypted first credentials 

>K ^ ] from the authentication block; 

forming at the client a first secret based on a client's secret and the 
challenge; 

forming a first authentication key at the client by using the first secret; and 
25 decrypting the first authentication key at the client using the encrypted first 

credentials; 

characterised in that 

the decryption of the encrypted first credentials are independent of sending 
any response based on the client's secret from the client to the authentication 
30 block. 



According to a third aspect of the invention there is provided a method of 
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authenticating a client, comprising the steps of: 

receiving by an authentication block client identity information from a client; 

obtaining for the authentication block at least one challenge and at least 
one first secret based on a client's secret specific to the client; 

forming first credentials; 

forming a first authentication key using the at least one first secret; 

encrypting the first credentials using the first authentication key; 

sending the at least one challenge and the encrypted first credentials to the 

client; 

receiving from the client a message containing a first information; and 
checking if the first credentials have been used to cryptographically process 
the first information; 

characterised in that 

the encryption of the first credentials is independent of the authentication 
block receiving any response based on the client's secret from the client. 

According to a fourth aspect of the invention there is provided a method of 
authenticating a client, comprising the steps of: 

sending client identity information to an authentication block; 

obtaining at least one challenge and at least one first secret by the 
authentication block based on a client's secret specific to the client; 

forming first credentials; 

forming a first authentication key using the at least one first secret; 

encrypting the first credentials using the first authentication key by the 
authentication block; 

sending the at least one challenge and the encrypted first credentials to the 
client by the authentication block; 

forming the first authentication key at the client; 

decrypting the encrypted first credentials at the client using the first 
authentication key; and 

authenticating the client by using the first credentials. 



WO 02/052784 



PCT/IB01/02822 



15 

According to a fifth aspect of the invention there is provided an authentication 
system, comprising an authentication block and a client; and: 

a first input at the authentication block for receiving client identity 
information; 

5 a second input at the authentication block for receiving at least one 

challenge and at least one first secret based on a secret specific to the client; 
a first processor at the authentication block 
for forming first credentials; 

for forming a first authentication key using the at least one first 

10 secret; and 

for encrypting the first credentials using the first authentication key; 
an output at the authentication block for providing the at least one challenge 
and the encrypted first credentials to the client; and 

a first processor at the client for forming the first authentication key and for 
15 decrypting the encrypted first credentials using the first authentication key; 
characterised in that 

the encryption of the first credentials is independent of the authentication 
block receiving any response based on the client's secret from the client 

20 According to a sixth aspect of the invention there is provided a client to an 
J authentication system comprising an authentication block; the client comprising: 

a first output for providing the authentication block with a client identity 
information; 

a first input for receiving at least one challenge and encrypted first 
25 credentials; 

a first processor 

for forming a first secret based on a client's secret and the challenge; 
for forming a first authentication key by using the first secret; and 
for decrypting the encrypted first credentials using the first 
30 authentication key; 

characterised in that 
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the decryption of the encrypted first credentials is independent of sending 
any response based on the client's secret from the client to the authentication 
block. 

According to a seventh aspect of the invention there is provided an authentication 
block for an authentication system comprising a client; the authentication block 
comprising: 

a first input for receiving client identity information; 

a second input for receiving at least one challenge and at least one first 
secret based on a secret specific to the client; 
a first processor 

for forming first credentials; 

for forming a first authentication key using the at least one first 

secret; and 

for encrypting the first credentials using the first authentication key; 

an output for providing the client with the at least one challenge and the 
encrypted first credentials; 

the first input being further adapted to receive from the client a message 
containing a first information; and 

the first processor being further adapted to check if the first credentials have 
been used to cryptographically process the first information; 

characterised by in that 

the encryption of the first credentials is independent of the authentication 
block receiving any response based on the client's secret from the client. 

According to an eighth aspect of the invention there is provided a computer 
program product for controlling a client; the computer program product comprising: 

computer executable code to enable the client to send client identity 
information to an authentication block; 

computer executable code to enable the client to receive from the 
authentication block at least one challenge and encrypted first credentials; 



1 
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computer executable code to enable the client to form a first secret based 
on a client's secret and the challenge; 

computer executable code to enable the client to form a first authentication 
key by using the first secret; and 
5 computer executable code to enable the client to decrypt the encrypted first 

credentials using the first authentication key; 

characterised by in that 

the decryption of the encrypted first credentials are independent of sending 
any response based on the client's secret from the client to the authentication 
' _10 block. 



According to a ninth aspect of the invention there is provided a computer program 
product for controlling an authentication block in order to enable the authentication 
block to authenticate a client, the computer program product comprising: 
15 computer executable code to enable the authentication block to receive 

client identity information from a client; 

computer executable code to enable the authentication block to obtain at 
least one challenge and at least one first secret based on a secret specific to the 
client; 

20 computer executable code to enable the authentication block to form first 

^ credentials; 

computer executable code to enable the authentication block to form a first 
authentication key using the at least one first secret; 

computer executable code to enable the authentication block to encrypt the 
25 first credentials using the first authentication key; 

computer executable code to enable the authentication block to send the at 
least one challenge and the encrypted first credentials to the client; 

computer executable code to enable the authentication block to receive 
from the client a message containing first information; and 
30 computer executable code to enable the authentication block to check if the 

first credentials have been used to cryptographically process the first information; 
characterised by in that 
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the encryption of the first credentials are independent of receiving any 
response based on the secret specific to the client from the client. 

The embodiments of one aspect also apply to various other aspects of the 
invention. In sake of brevity, the embodiments have not been repeated in 
connection with every aspect of the invention. A skilled reader will appreciate the 
advantages of the various aspects based on the advantages of the first aspect of 
the invention. 

The invention will now be described, by way of example only, with reference to the 
accompanying drawings, in which: 

Fig. 1 shows an overview of a Kerberos system according to Kerberos 

version 4; 

Fig. 2 shows the operation of the Kerberos system of Fig. 1 ; 

Fig. 3 shows an authentication procedure of WO 0002406; 

Fig. 4 is a block diagram showing a client according to a preferred 

embodiment of the invention; 
Fig. 5 is a block diagram showing an authentication server according to the 

preferred embodiment of the invention; 
Fig. 6 shows the operation of a Kerberos system modified according to a 

preferred embodiment of the invention; 
Fig. 7 shows a block diagram of a Wireless Local Area Network 

authentication system according to an embodiment of the invention; 
Fig. 8 shows an authentication procedure of the authentication system of 

Fig. 7; 

Fig. 9 shows an authentication procedure at the client according to yet 

another embodiment of the invention; and 
Fig. 1 0 shows the construction of the parameter AUTS. 
Figs 1 to 3 have been described in the foregoing. 

Fig. 4 is a block diagram showing a client c according to a preferred embodiment 
of the invention. The client c comprises a telephony functionality block Tel, an IP 
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terminal functionality block IP for connecting to an IP network, a non-volatile 
memory ROM, a random access memory RAM C , a user interface Ul c , a SIM reader 
with a SIM therein, software SW C stored in the ROM c , and a central processing 
unit CPU C for running the software c and controlling the operation of the client c 
5 accordingly. The telephony functionality block Tel provides conventional telephony 
functionality such as making telephone calls and modern communication 
functionality such as making data calls, sending or receiving facsimiles, e-mails. 
Typically, the Tel is compatible with the GSM phase 2-k It may further support the 
General Packet Radio Service (GPRS), which is a packet based communications 

' 1 0 service built on GSM. In that case, the client c supports two different kinds of 

packet data networks. The operation of the client c will be described in detail with 
reference to Fig. 6. 

Fig. 5 shows a block diagram of an authentication server AS according to the 
15 preferred embodiment of the invention. The authentication server AS comprises an 
Input/Output block IO A s, a key database (possibly geographically distributed) DB 
for storing pass keys as such or as hashed, a non-volatile memory ROM AS , a 
random access memory RAM AS , software SW A s stored in the ROM A s, an access 
to an Authentication Centre AuC of a telecommunication network (typically of a 
20 GSM network), and a central processing unit CPU A s for running the software AS 
( _J and controlling the operation of the AS accordingly. The operation of the 
authentication server will be described in detail with reference to Fig. 6. 

Fig. 6 shows the operation of a Kerberos system modified according to the 
25 preferred embodiment of the invention. The system comprises the client c of Fig. 4 
and the authentication server AS of Fig. 5. Corresponding reference numerals 
have been applied to corresponding messages and steps described in relation to 
Fig.s 1 and 2. The steps will now be described. 

30 Step 61: The SIM provides the International mobile subscriber identity (IMS!) of a 
telecommunications network subscriber (whose SIM it is) to a client c (mobile 
node, the ID of the TGS (ID tg s), and a first time stamp or a random number (as a 
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replay attack protector, or nonce!) corresponding to the time when the request was 
sent. 

Step 62: The client c sends a KRB_AS_REQ message, that is, a ticket tgs request, 
comprising the IMSI, the ID tgs and the nonce! to the AS. 

Step 63: The AS requests for n (one or more) GSM triplets from an AuC of the 
mobile telecommunications network that is identified by the IMSI. These triplets 
are formed using a cryptographic function and subscriber's secret known both by 
the SIM and the AuC. 

Step 64: The AuC replies with one or more sets of challenges (RAND) and GSM 
session keys (Kg Sm ) and typically also corresponding signed responses (SRES). 
The AS forms a first authentication key Kc using the n GSM session keys K gsm 
and/or signed responses SRES of the GSM triplets as follows: Kc = hash! [ n x 
Kgsm, n x SRES, noncei], wherein hashi is a first hash function, which is a one-way 
hash function known both by the client c and the AS. x is a notation of n K gsm 
parametres, not of a multiplication. According to the preferred embodiment of the 
invention, the signed responses are not compared at all (and therefore not 
transmitted in clear text) so that the received SRESs can also be used in forming 
the Kc. Use of more secret data in forming the Kc increases its cryptographic 
strength. Alternatively, only GSM session keys K gsm or signed responses SRESs 
can be used. Furthermore, in generating the first authentication key K c the number 
of GSM session keys K gsm used may differ from the number of SRESs used. It is 
only necessary for the client c to know how the K c is generated. The Kc will serve 
in authentication between the AS and the client c. Furthermore, a first session key 
Kc^s is formed by the AS. The Kc.t^ can be, for example, a random key generated 
by the AS. 

Step 23': The AS forms a ticket granting ticket ticket tgs as has been described in 
the foregoing in relation to the prior art section. Step 23' differs from step 23 
described in the prior art section so that the AS sends also the n RANDs that have 
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been used in generating the K c in addition to the ticket tgs and the K Cf t gs encrypted 
with the K c . The message sent from the AS to the c in step 23' can be referred to 
as a KRB_AS_REP message. 

5 Step 65: The client c gives the n RANDs to the SIM, which forms corresponding n 
pairs of SRES and K gS m values. 

Step 66: The SIM gives the n pairs of SRES and K gsm values formed in the 
previous step to the client c. Next, the client c forms an own version of the K c using 
( "10 the SRES and the K gsm values in a similar fashion that the AS had earlier done. 
After having its own version of the K c , the operation of the system then follows 
steps 26 to 29 of the standard Kerberos version 5 protocol explained in the 
foregoing with reference to Fig. 2. 

15 Steps 24 and 25 are replaced by steps 65 and 66, because the authentication can 
take place automatically if the user has accepted access to his SIM. 

As mentioned in the foregoing, the IMSI is sent from the client c to the AS and 
then RANDs are sent from the AS to the client c. This messaging can 
20 implemented in various manners, among which the implementation according to 
\_J the preferred embodiment is next described. 

Kerberos version 5 authentication service exchange comprises an initial 
transmission of optional pre-authentication data (PA_DATA) from the client c to 

25 the AS. The presence of the pre-authentication data is shown in a flag PRE- 
AUTHENT. The use of PA_DATA is not standardised but, according to Stallings, 
"the MIT implementation of version 5 has encrypted timestamp pre-authentication 
block containing a random confounder, a version number, and a timestamp, 
encrypted in the client's password-based key". The "pre-authentication block", or 

30 data, is then decrypted by the AS. The AS can then verify the true authenticity of 
the client c and send tickets only if the pre-authentication will be confirmed. 
Stallings continues by describing another possibility that utilises a smart card that 
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generates a series of passwords each having its own limited period of validity. The 
passwords can be based on the user's password, but as they change, the 
passwords transmitted are in effect arbitrary and are difficult to determine. Use of 
a smart card reader can be indicated by a HW_AUTHENT flag, which identifies the 
5 protocols which require use of hardware that is expected to be only in the 
possession of the correct client c. 



In the preferred embodiment of the invention, the PAJDATA and HW_AUTHENT 
flags are utilised in the present invention so that the IMSI can be transmitted in the 
10 PA_DATA field and the HW_AUTHENT flag can be used to indicate the use of a ' 
SIM for authentication. Instead of using the PA_DATA for any pre-authentication, 
the AS requests, responsive to a dedicated value of the HW_AUTHENT flag, GSM 
triplets from the AuC of the subscriber. The correct AuC is found by using the 
IMSI. 

15 

The AS sends the n RANDs to the client c in a standard Kerberos version 5 
message KRB_AS_REP, in a pre-authentication data (PA_DATA) field. After 
receiving the RANDs, the client c can form its own version of the K c and decrypt 
the K C(t g S . 

20 

In the preferred embodiment, the PA_DATA field is used for sending the IMSI from , y 
the client c to the AS. As the client's ID ID C , a fake ID C that is not the true ID of the 
client (for example a random value or a constant such as zero), is used as the ID C . 
The (fake) ID C is embedded in all the following authentication messages in which 

25 tickets are requested or granted. As an advantage of sending the IMSI in the 
PA_DATA field, the IMSI will not become part of a series of further messages. This 
is good since the IMSI identifies the subscriber. For security reasons, it is 
desirable to limit its general availability. Use of a pre-authentication flag and data 
fields is also advantageous, in order to provide a standardised way to indicate to 

30 the AS that a method of using a SIM-authentication according to the invention is 
being used. Standard Kerberos version 5 can be used with small changes and no 
proprietary protocols need to be run first in order to obtain the first session key 
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K Cf tgs for use in the Kerberos version 5 protocol. 

It was also mentioned in the previous paragraph that the client's ID ID C can be 
given an arbitrary value. Furthermore, the ID C can be chosen later on by the AS. 
5 The ID C is sent back from the AS as cleartext so that it does not matter if the ID C 
changes after the client c has sent the first message with an arbitrary initial ID C . It 
is advantageous for the AS to choose the 1D C because it provides an opportunity 
for centralised allocation of identities so that each identity can be unique during its 
life-time. 

Go 

Fig. 7 shows a block diagram of a Wireless Local Area Network authentication 
system 70 according to an embodiment of the invention. The system 70 comprises 
a client c, an access point AP, a Kerberos key distribution centre KSS containing 
both a Kerberos Authentication Server (AS, not shown in Fig. 7) and a Ticket- 
15 Granting Server (TGS, not shown in Fig. 7). The AP functions as a proxy server 
between the client c and the KSS, as will next be illustrated with reference to Fig. 
8. Additionally, the AP contains Kerberos Service Server (V, not shown in Fig. 7) 
functionality. 

20 Fig. 8 shows an authentication procedure of the authentication system 70 of Fig. 7. 
O The procedure starts from steps 810 and 812, in which the AP sends 
advertisements informing the client c about itself and the client c associates with 
the AP. Next, an Extensible Authentication Protocol (EAP) identity request 
message is sent by the AP (step 814) to the client c. The client c replies with an 

25 EAP Identity Response (step 816). The AP then sends an EAP-GSS Request 
(step 818) to the client c. All these steps 810 to 816 are familiar to a person skilled 
in the art, for example from a publication "TGe Security Baseline", November 
2000, by D. Halasz, S. Norman, G. Zorn, B. Aboba, T. Moore, J. Walker, B. Beach, 
B. O'Hara, slide 18, (IEEE 802.1 1-00/419). 

30 

Next, the client c forms (step 820) a message AS_REQ, which corresponds to the 
KRB_AS_REQ explained in the foregoing and then the client c sends the message 



WO 02/052784 



PCT/IB01/02822 



24 

to the AP encapsulated by IAKERB and further EAP-GSS protocols. Both IAKERB 
and EAP-GSS protocols are known to a person skilled in the art, see for example 
"Generic Security Service Application Program Interface, Version 2, Update 1" 
(RFC 2743), January 2000, by J. Linn and "Initial Authentication and Pass 
5 Through Authentication Using Kerberos V5 and the GSS-API (IAKERB)", 
November 2000, by M. Swift, J. Trostle, B. Aboba and G. Zorn (draft-ietf-cat- 
iakerb-05.txt). 

The AP forwards (step 822) the AS_REQ message to the KSS, which replies (step 
10 824) with an AS_REP message to the AP. The AP forwards (step 826) the * > 

AS_REP encapsulated by the IAKERB and EAP-GSS protocols to the client c. The 
AS_REP corresponds to the KRB_AS_REP explained in the foregoing. 

In steps 828 to 834 a ticket service granting ticket is requested and granted to the 
15 client c. 

As was mentioned in description of Fig. 7, the AP has two roles. The AP operates 
as an IAKERB proxy when it forwards the clients AS_REQ/AS_REP and 
TGS_REQ/TGS_REP messages (steps 820 to 834). In addition, the AP contains a 
20 Kerberos Service Server (V), for example for providing access to a network, such 

as the Internet. In steps 828 to 834, the client c obtains a ticket v for the AP from ^ 
the KSS. In steps 840 and 842 (AP_REQ and AP_REP), the client c uses the 
ticketv to obtain a service from a service server, for example an access to the 
Internet through the AP. 

25 

Typically, a separate session key will be used between the client and the access 
point (distributed in steps 840 to 842) and the SIM-generated key will only be used 
in the authentication service exchange. 

30 In yet another alternative embodiment, the IMSI can be transmitted from the client 
c to the AP in the EAP Identity Response message (step 816), in which case it 
need not be transmitted in the AS_REQ message. 
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Fig. 9 shows an authentication sub-procedure at the client according to yet 
another embodiment of the invention. In this embodiment the client has a UMTS 
SIM USIM instead of a GSM SIM. On describing the process at the client the 
5 process at the network end becomes also clear to a skilled person. The sub- 
procedure corresponds to the UMTS Authentication and Key Agreement (AKA) 
procedure and is used to obtain the UMTS quintet. The UMTS quintet contains 5 
data items: a challenge RAND, an expected response XRES that should match 
with a response RES that the USIM generates, a cipher key CK, an integrity key IK 
l _ 10 and a network Authentication TokeN AUTN. The UMTS quintet is typically 
received in the PA_DATA field, as described earlier with reference to Fig. 6. 

The sub-procedure exemplifies how a sequence number SQN can be embedded 
in the authentication and how it can be checked and further re-synchronised in 
15 case it is out of synchronisation. 

The UMTS quintet has been generated typically by an AuC of a UMTS operator of 
the subscriber (USIM) using a shared secret K (corresponding to Kj, shared secret 
in GSM). The quintet is formed such that only two data items need to be 
20 transmitted to the USIM to enable it to obtain the entire quintet, namely the RAND 
l w and the AUTN. The client receives these two data items. The USIM then obtains 
the quintet using the AUTN, the RAND and the K. Typically, the USIM generates 
RES, CK and IK using just the K and the RAND, with respective three different 
authentication functions f2 to f4 known both by the USIM and the AuC. 

25 

The USIM also generates an expected message authentication code XMAC using 
the RAND, AUTN and K. The AUTN contains a field SQN e AK, wherein AK is an 
anonymity key, an Authentication Management Field AMF, and a Message 
Authentication Code MAC. The first-mentioned field allows the USIM to obtain the 
30 XMAC, to be compared against the MAC. The USIM first generates the AK using 
RAND and K with an authentication function f5. Next, the USIM computes (SQN e 
AK) © AK and obtains the SQN (note: the term of the formula that is in brackets is 
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the field of AUTN and the AK in the end of the formula is obtained by the USIM). 
The USIM can then compute the XMAC with the K, the SQN, the AMF and the 
RAND, using a first authentication function f 1 . 

5 The USIM compares the XMAC with the MAC which was included in the AUTN. If 
they are different, the client sends a user authentication reject message back to 
the AuC with an indication of the cause and the client abandons the ongoing 
authentication procedure. In this case, the AuC may initiate a new identification 
and authentication procedure towards the client. 

10 O 
The USIM also verifies that the received sequence number SQN is in the correct 
range. The SQN may not differ more than by a predetermined amount of the SQN 
held by the USIM. If the USIM considers the sequence number not to be in the 
correct range, it sends synchronisation failure message back to the AuC including 

15 an appropriate parameter, and abandons the ongoing procedure. 

The above-described sub-procedure fits in the framework of the Kerberos 
Authentication Service Exchange. It is further explained in the following in the 
framework of Kerberos based authentication service exchange. 

20 

The client c requests for a ticket tgs by sending a KRB_AS_REQ message to the 
AS. The message has the following basic format: 
Options II IDc II IMSI II Realm c II ID tgs II times II Nonce/ 

The KRB_AS_REQ message is as in standard Kerberos, except that it contains 
the client's IMSI. The IMSI may be transmitted in the client identity field (ID C ), for 
example using the Kerberos name type PRINCIPAL, or a new name type reserved 
for UMTS. Kerberos supports various authentication mechanisms with the pre- 
authentication data (padata) field of the KRB_AS_REQ and KRB_AS_REP 
messages. 
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In an alternative embodiment the IMSI is transmitted using the Kerberos padata 
field. This has the advantage that the client uses an identity other than the IMSI as 
the ID C in all Kerberos messages, and IMSI has to be transmitted only once. 

5 In yet another alternative embodiment, to avoid sending the IMSI in the 
subsequent Kerberos messages, the AS chooses an identity for the client c, 
generates the ticket for this new identity and transmits the identity with the ticket tgs 
of the KRB__AS_REP message. 

•~t0 The AS responds by a KRB_AS_REP message to the client c. The message 
KRB_AS_REP has the following basic format: 

Realm c l!ID c IITickettgslln RANDslln AUTNsllE K c[K c , tgslltimesllNonceTllRealmtgsl 

IDtgs] 

15 where n is an integer (at least 1), K c = h(n CK, n Ik, Nonce-i) and the function h() is. 
a one-way hash function. In an alternative embodiment, Kc = h(n CK, n IK, n RES, 
Noncei) 

The KRB_AS_REP message is similar to the prior art Kerberos correspondent 
20 except that it contains n RANDs and AUTNs. The RANDs and AUTNs can be 
^ ' contained in the padata field of the KRB_AS_REP message. 

On receipt of KRB_AS_REP, the client first verifies the n AUTNs as in standard 
UMTS AKA. If the n AUTN parameters check out properly, the client runs the 

25 UMTS AKA algorithms on the USIM and derives the K c from the n quintets and 
Noncei. Then the client is able to decrypt the encrypted portion of KRB_AS__REP 
and verify it, like in normal Kerberos authentication. If the verifications are 
successful, the client has obtained a ticket-granting ticket and a ticket-granting 
server session key. From this point onwards, the client operates as any other 

30 Kerberos client. The client does not need the USIM until the ticket t g S expires and 
the client needs to request a new ticket tgs by running the Authentication Service 
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Exchange again (unless the USIM is needed for other purpose such as placing an 
ordinary UMTS telephone call). 

As in standard Kerberos, in the UMTS AKA case the AS is also unable to Verify 
that the KRB_AS_REQ is coming from a legitimate client c. On receipt of the 
KRB_AS_REQ message, the AS fetches UMTS quintets for the client, generates 
the K c key and sends the KRB_AS_REP message. The AS needs not save the K c 
key or any other status information for the client. 

If the ticket was requested by a legitimate client (that is, the client c possessing the 
USIM having the IMSI used), the client can derive the key Kc and decrypt the 
encrypted portion of the KRB_AS_REP message and obtain the ticket tgs . As in 
standard Kerberos, only legitimate clients c are able to use the ticket tgs received in 
the KRB_AS_REP message. 

Next, the client c obtains the SQN out of at least one rand and AUTN (typically the 
first ones of the n RANDs and AUTNs) and checks whether it is in the correct 
range. 

If the SQN is in the correct range (not too far from the SQN M s), the client c 
approves the ticket tgs and can use it. Otherwise, the client c sends a new 
KRB_AS_REQ as a re-synchronisation request message (in step (3)) containing 
an AUTS corresponding to the first RAND and AUTN. The AUTS is a parameter 
used to re-synchronise the SQN. The construction of the parameter AUTS is 
shown in Figure 10. There a MAC-S (Message Authentication Code for the re- 
Synchronisation) is formed to be a part of the AUTS. The KRB_AS_REQ message 
used now has the following basic format: 

Options II IDc II IMSI II RAND II AUTS II Realm c II ID tgs II times II Nonce! 

Responsive to the re-synchronisation request message, the AS causes the AuC to 
synchronise its SQN with the USIM (to SQN MS ), retrieves a new set of UMTS 
quintets and sends them to the client c a new KRB_AS_REP message which is 
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now formed using the synchronised SQN (i.e. where the RANDs and AUTNs are 
based on SQNs in syncronisation with the USIM's SQN MS ). The KRB_AS_REP 
now has the following basic format: 

Realm c IIID c IITickettg S ll n RANDslin AUTNsllE K c[K c , tgslltimesllNonceill Realm tgs II 

5 IDtgs] 

It is a remarkable advantage of this embodiment that UMTS authentication can be 
extended to Kerberos compliant Ticket Granting server and Kerberos Service 
Servers (also known as application servers) without any modifications to them. It 
10 suffices that the Kerberos client and the AS are UMTS AKA aware. The Kerberos 
TGS and service servers V need not to be UMTS AKA aware. The AS may have 
an interface to the UMTS authorisation network, similarly as the network Operator 
Wireless LAN (OWLAN) AS to the GSM network. The Nokia Authentication Server 
is an example of such an OWLAN AS. 

15 

The different embodiments of the invention allow use of various 
telecommunications network identifying modules, including SIMs and USIMs, for 
authenticating clients to various other data networks or their services using tickets 
that grant the access to them or their services. For example, a UMTS mobile 

20 telecommunication device can use both UMTS telecommunications services 
J provided by its telecommunications operator (over radio interface) and Wireless 
(and/or wired) LAN services. The device can obtain a strong and relatively reliable 
first authentication key or session key K c based on the device's user identification 
module and use that session key without need to send back any "signed 

25 response" such as RES or SRES and thus that data can further be used in 
creation of the session key. 

Moreover, the generation of the session key based on the mobile 
telecommunications network's credentials (GSM triplet data or UMTS quintet data) 
30 allows fast handovers for access point roaming. 

Particular implementations and embodiments of the invention have been 
described. It is clear to a person skilled in the art that the invention is not restricted 
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to details of the embodiments presented above, but that it can be implemented in 
other embodiments using equivalent means without deviating from the 
characteristics of the invention. The scope of the invention is only restricted by the 
attached patent claims. 
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Claims 

1. Method of authenticating a client (c), comprising the steps of: 

sending client identity information (IMSI) to an authentication block (AS); 
obtaining at least one challenge (RAND) and at least one first secret (K gsm , 
5 SRES;CK,IK,RES) for the authentication block (AS) based on a client's secret (Ki) 
specific to the client (c); 

forming first credentials (K c ,tgs); 

forming a first authentication key (K c ) using the at least one first secret 
(K gsm ,SRES;CK,IK,RES); 
' _ 1 0 encrypting the first credentials (K c ,t g s) using the first authentication key (K c ); 

sending the at least one challenge (RAND) and the encrypted first 
credentials (K c> tg S ) to the client (c); 

forming the first authentication key (Kc) at the client (c); and 

decrypting the encrypted first credentials (K c ,t gs ) using the first 
15 authentication key (K c ) at the client; characterised by 

the encryption of the first credentials (K Cftgs ) being independent of the 
authentication block (AS) receiving any response based on the client's secret 
(Ki;K) from the client (c). 

20 2. A method according to claim 1, characterised by the first credentials (K Cttgs ) 
being encrypted before the authentication block (AS) receives any response 
based on the client's secret (Ki;K) from the client (c). 

3. A method according to claim 1 or 2, characterised by the sending of the at 
25 least one challenge and the encrypted first credentials occurring in a same 
message. 



4. A method according to any of the preceding claims, characterised by the at 
least one challenge (RAND) and the at least one first secret corresponding to 
30 particular at least one sequence number (SQN) and conveying the at least one 
sequence number (SQN), and the method further comprising the steps of: 
maintaining a sequence number counter (SQN M s) at the client (c); 
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obtaining at the client (c) the sequence number (SQN) using at least one of 
the at least one challenge (RAND) and the at least one first secret (K gsm ,SRES; 
CK.IK.RES); and 

checking at the client (c) if the sequence number (SQN) falls within a 
5 predetermined range. 

5. A method according to claim 4, characterised by the method further 
comprising the step of initiating a sequence number synchronisation in case 
the sequence number (SQN) does not fall within the predetermined range. 

10 1 J 

6. A method according to claim 5, characterised by the initiation of the 
sequence number synchronisation comprises a step of forming a 
synchronisation request message containing at least one challenge (RAND) 
out of the at least one challenge. 

15 

7. A method according to any of claim 5 to 6, characterised by the initiation of 
the sequence number synchronisation comprising a step of forming a 
synchronisation request message containing at least the sequence number 
counter (SQN M s). 

20 

8. A method according to any of claims 5 to 7, characterised by the initiation ^ 
of a sequence number synchronisation comprising a message authentication 

code (MAC-S). 

25 9. A method according to any of the preceding claims, characterised in that no 
response based on the client's secret (Ki) is sent from the client (c) to the 
authentication block (AS). 

10.A method according to any of the preceding claims, characterised in that 
30 the forming of the first authentication key (K c ) is based on two or more first 
secrets. 
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11. A method according to any of the preceding claims, characterised in that 
the step of obtaining the at least one challenge (RAND) and at least one first 
secret (K gsm , SRES) to the authentication block (AS) based on a client's secret 
(Ki) specific to the client (c) occurs before a need to authenticate the client. 

5 

12. A method according to any of the preceding claims, characterised in that 
the client identity information is subscriber identity. 

13. A method according to any of the preceding claims, characterised by the 

C \ 

- 10 method further comprising the step of forming by the authentication block an 
identification for use in a following authentication message for the client. 

14. A method according to any of the preceding claims, characterised by 

the method further comprising the step of receiving a replay attack protector 
15 (nonce-i) from the client to the authentication block; and 
the forming of the first authentication key comprising a sub-step of using a 
hash function of at least the first secret and the replay attack protector. 

15. A method according to any of the preceding claims, characterised by the 
20 forming of the first credentials comprising the sub-steps of: 

1 - ' encrypting first information (ID C ) corresponding to the client with a second 

authentication key (K tgs ) not known by the client (c); and 

verifying that the first information has been encrypted using the second 
authentication key (K tgs ). 

25 

16. A method according to any of the preceding claims, characterised by the 
method further comprising the step of generating a service request message 
using cryptographically the first decrypted credentials. 

30 17. Method of authenticating a client (c), comprising the steps of: 

sending client identity information (IMSI) to an authentication block (AS); 
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receiving by the client at least one challenge (RAND) and encrypted first 
credentials (K c>tgs ) from the authentication block (AS); 

forming at the client a first secret (Kgsm, SRES) based on a client's secret 
(Ki) and the challenge (RAND); 

forming at the client (c) by using the first secret (K gsm , SRES) a first 
authentication key (K c ); and 

decrypting the encrypted first credentials (K c .t gs ) using the first 
authentication key (K c ) at the client; characterised by 

the decryption of the encrypted first credentials (Kc >t gs) being independent of 
sending any response based on the client's secret (Ki) from the client (c) to the 
authentication block (AS). 

18. Method of authenticating a client (c), comprising the steps of: 

receiving by an authentication block (AS) client identity information (IMSI) 
from a client (c) ; 

obtaining for the authentication block (AS) at least one challenge (RAND) 
and at least one first secret (K gsm , SRES) based on a client's secret (Ki) specific to 
the client (c); 

forming first credentials (Kc,t g s); 

forming a first authentication key (Kc) using the at least one first secret 
(K gsm) SRES); 

encrypting the first credentials (K c , tg s) using the first authentication key (K c ); 

sending the at least one challenge (RAND) and the encrypted first 
credentials (K Cl t gs ) to the client (c); 

receiving from the client (c) a message containing a first information; and 

checking if the first credentials have been used to cryptographically process 
the first information; characterised by 

the encryption of the first credentials (K c ,t 9s ) being independent of receiving 
any response based on the client's secret (Ki) from the client (c) to the 
authentication block (AS). 

19. Authentication system, comprising an authentication block (AS) and a client (c); 
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and: 

a first input (IO A s) at an authentication block (AS) for receiving client identity 
information (I MSI); 

a second input (IO A s) at the authentication block (AS) for receiving at least 
5 one challenge (RAND) and at least one first secret (K gS m, SRES) based on a 
client's secret (Ki) specific to the client (c); 

a first processor (CPU A s) at the authentication block (AS) 
for forming first credentials (K c ,tg S ); 

for forming a first authentication key (K c ) using the at least one first 
( _ 1 0 secret (K gsm ,SRES); and 

for encrypting the first credentials (K c ,tg S ) using the first authentication 

key (K c ); 

an output (IOas) at the authentication block (AS) for providing the at least 
one challenge (RAND) and the encrypted first credentials (Kc.tgs) to the client (c); 
15 and 

a first processor (CPU C ) at the client (c) for forming the first authentication 
key (K c ) and for decrypting the encrypted first credentials (K Ctt g S ) using the first 
authentication key (K c ); characterised by 

the encryption of the first credentials (K Cit g S ) being independent of receiving 
20 any response based on the client's secret (Ki) from the client (c) to the 
O' authentication block (AS). 

20. Client (c) to an authentication system comprising an authentication block (AS); 
the client comprising: 

25 a first output (IO c ) for providing the authentication block (AS) with a client 

identity information (IMSI); 

a first input (IO c ) for receiving at least one challenge (RAND) and encrypted 
first credentials (K c>t g S ); and 

a first processor (CPU C ) 
30 for forming a first secret (K gS m, SRES) based on a client's secret (Ki) 

and the challenge (RAND); 
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for forming a first authentication key (K c ) by using the first secret 
(K gsm , SRES); and 

for decrypting the encrypted first credentials (K c ,tg S ) using the first 
authentication key (K c ); 
characterised by 

the encryption of the first credentials (K c ,tg S ) being independent of receiving 
any response based on the client's secret (Ki) from the client (c) to the 
authentication block (AS). 

21. An authentication block (AS) for an authentication system comprising a client 
(c); the authentication block comprising: 

a first input (IO A s) for receiving client identity information (I MSI); 
a second input (IO AS ) for receiving at least one challenge (RAND) and at 
least one first secret (K gsm , SRES) based on a client's secret (Ki) specific to the 
client (c); 

a first processor (CPU A s) 

for forming first credentials (Kc,t g s); 

for forming a first authentication key (K c ) using the at least one first 
secret (K gsm ,SRES); and 

for encrypting the first credentials (K c>t g S ) using the first authentication 

key (Ko); 

an output (IO AS ) for providing the client with the at least one challenge 
(RAND) and the encrypted first credentials (K c , t g S ); 

the first input (IO A s) being further adapted to receive from the client (c) a 
message containing a first information; and 

the first processor (CPU AS ) being further adapted to check if the first 
credentials have been used to cryptographically process the first information; 
characterised by 

the encryption of the first credentials (K c , t gs) being independent of receiving 
any response based on the client's secret (Ki) from the client (c) to the 
authentication block (AS). 
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22. Computer program product for controlling a client; the computer program 
product comprising: 

computer executable code to enable the client to send client identity 
information (IMSI) to an authentication block (AS); 
5 computer executable code to enable the client to receive from the 

authentication block (AS) at least one challenge (RAND) and encrypted first 
credentials (K C( t g s); 

computer executable code to enable the client to form a first secret (K gsm , 
SRES) based on a client's secret (Ki) and the challenge (RAND); 
_ AO computer executable code to enable the client to form a first authentication 

key (K c ) by using the first secret (K gsm , SRES); and 

computer executable code to enable the client to decrypt the encrypted first 
credentials (K Cl tg S ) using the first authentication key (K c ); characterised by 

the decryption of the encrypted first credentials (K c ,tgs) being independent of 
15 sending any response based on the client's secret (Ki) from the client (c) to the 
authentication block (AS). 

23. Computer program product for controlling a computer, for causing the 
computer to authenticate a client (c), the computer program product 

20 comprising: 

w computer executable code to enable the computer to receive client identity 

information (IMSI) from a client (c) to an authentication block (AS); 

computer executable code to enable the computer to obtain at least one 
challenge (RAND) and at least one first secret (K gsm , SRES) to the authentication 
25 block (AS) based on a client's secret (Ki) specific to the client (c); 

computer executable code to enable the computer to form first credentials 

(K c ,tgs); 

computer executable code to enable the computer to form a first 
authentication key (K c ) using the at least one first secret (K gsmj SRES); 
30 computer executable code to enable the computer to encrypt the first 

credentials (K Cttgs ) using the first authentication key (K c ); 
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computer executable code to enable the computer to send the at least one 
challenge (RAND) and the encrypted first credentials (K Citgs ) to the client (c); 

computer executable code to enable the computer to receive from the client 
(c) a message containing a first information; and 

computer executable code to enable the computer to check if the first 
credentials have been used to cryptographically process the first information; 
characterised by 

the encryption of the first credentials (K c ,t g s) being independent of receiving 
any response based on the client's secret (Ki) from the client (c) to the 
authentication block (AS). 

24. Computer program product for controlling a data communications network 
entity; the computer program product comprising: 

computer executable code to enable the data communications network 
entity to implement the method according to any one of claims 1 to 1 8. 
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